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© In a computer network, a broker mechanism 
allocates a plurality of servers, each having an avail- 
able resource capacity, to a plurality of clients for 
delivering one of several services to the clients. The 
broker operates by monitoring a subset of all avail- 
able servers capable of delivering the requested 
service. The allocation is based on developing a 
network policy for the plurality of servers by collect- 



ing a local policy for each of the servers. The broker 
receives client requests for the services and based 
on the network policy and available resource capac- 
ity suggests one of the servers, monitors in its 
subset for that particular service, to one of the cli- 
ents making a request. The server suggested en- 
forces its local policy by not allowing any connec- 
tions exceeding its available resource capacity. 
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© In a computer network, a broker mechanism 
allocates a plurality of servers, each having an avail- 
able resource capacity, to a plurality of clients for 
delivering one of several services to the clients. The 
broker operates by monitoring a subset of all avail- 
able servers capable of delivering the requested 
service. The allocation is based on developing a 
network policy for the plurality of servers by collect- 



ing a local policy for each of the servers. The broker 
receives client requests for the services and based 
on the network policy and available resource capac- 
ity suggests one of the servers, monitors in its 
subset for that particular service, to one of the cli- 
ents making a request. The server suggested en- 
forces its local policy by not allowing any connec- 
tions exceeding its available resource capacity. 
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Field Of The Invention 

This invention relates generally to the allocation 
of resources within a computer network architec- 
ture and. more particularly, to the use of a broker 
mechanism which responds to a client's or end 
user's request for some service and suggests a 
server to the client capable of supplying the re- 
quested service. 



Background Of The invention 

Present day computer network architectures 
have become more and more complex. For exam- 
pie, a network may comprise multiple devices, 
such as several computer systems, terminals, pe- 
ripherals, etc., all linked together in order to ex- 
change information and share resources. 

Other more complex networks may comprise 
thousands of devices of varying technical capabil- 
ities. In many applications, both local area networks 
(LANs) and wide area networks (WANs) are con- 
nected to form parts of a single network. For exam- 
ple, a network can. include a local area component, 
a wide area component and a component involving 
communication between computers of different 
vendors, such as a multi-vendor communication 
network. 

The process for designing computer networks 
of this type involves a complex analysis of the 
customer requirements, the price factor for the 
various products, the necessary communication 
lines, and other technical and business consider- 
ations. The allocation and planned use of the var- 
ious resources to support the network needs is now 
part of the normal capacity planning cycle done by 
a network manager when setting up the network for 
a customer. 

8ecause of the potential to form complex net- 
works, a computer network client has a wide range 
of resources available to supply requested service. 
This advantage, however, also adds to the problem 
of networks and resource management. It is there- 
fore desirable to obtain delivery of these services 
through network service names. A service offers 
clients capacity to use in accessing resources in 
the network. 

In these computer networks, a server, made up 
of both hardware and software, may be used as an 
agent between a client and one or more resources 
to deliver the requested service to the ciient. The 
server's software program provides "actions" for a 
client using one or more resources. These actions, 
for example, may be transmission of packets over 
a communication line - a communication server; 
computations in a problem - a CPU server; in- 
formation access in a data base - a data base 
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server; network addressing information distributed 
throughout a network and associated with a re- 
quested service - a name server; or other similar 
and multiple combinations of these functions. 
5 Because networks may include multiple serv- 

ers generally delivering the same action, a client 
may access any one of these servers with equal 
delivery of the action. One of the disadvantages in 
the prior art is the inability to group these servers 
>o providing the same action. This grouping of servers 
can be seen as a "network service'*. 

To overcome shortcomings of the prior art an 
ideal system for a client to request a service in a 
complex network should fulfill two requirements. 
'5 First, the request must include generic accessing 
of a particular network service name to provide a 
higher level interface abstraction than the current 
practice where each client knows of all server pos- 
sibilities. This has the advantage of substantially 
20 simplifying the decision process for the client in the 
case where multiple servers can deliver the re- 
quested service. The only requirement is the net- 
work service name rather than the name of each 
and every server offering the requested service. 
25 Second, the requested service must be guaranteed 
to exist for the client within the server for the 
duration of a connection. 

To supply a service to a client, it is known to 
use a broker mechanism coupled to the network for 
20 scheduling a server to a requesting client. The 
broker receives a request for access to a service 
from a client and transmits to the client the name 
of a server which can deliver the service to the 
client. One known type of broker operates by as- 
35 signing ar. vnire server to a client irrespective of 
the capacity needed by the client. 

A problem with the above broker method is the 
inefficient use of network resources. Prior brokers 
must continuously monitor all of the servers coup- 
*o led to the network, increasing the brokers overhead 
and the network traffic. Because the resource 
capacities of the servers and the necessary perfor- 
mance level to be allocated to the client are dy- 
namic factors, a broker mechanism which can dy- 
^5 namically allocate servers to clients using a pre- 
determined policy is needed. 



Summary Of The Invention 

50 

The present invention is a broker method and 
apparatus which, on one hand monitors the dy- 
namic status of a set of servers and. on the other 
hand, responds to requests from accessing clients 
55 concerning which member of that server set is 
capable of providing the requested service. 

The service limitations for the requested ser- 
vice are preferably established as a matter of poli- 

2 
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cy during the network design and modelling pro- 
cess by a system or network manager. Based upon 
the policy, the broker thus suggests to the client a 
server which is best able to satisfy the client's 
service request. The broker enables a client to use 
a service even though the client is unaware of the 
presence or absence of any individual servers with- 
in the network. 

According to one aspect of the invention, the 
client then requests the service from the recom- 
mended server, and the server is responsible for 
granting the request only if the server currently has 
the required capacity available for that service. 
Since the server makes the final determination of 
whether it has the available capacity to provide the 
requested service, there is no risk of overloading a 
server because the broker has out of date status 
information - for example, as when a server be- 
comes busy subsequent to its last status message 
transmitted to the broker. 

As indicated above, the suggestion of a server 
preferably is based on the network policy devel- 
oped by the network manager for the particular 
network. Because of the complex nature of present 
networks, a modelling process is used to develop a 
local policy for each server in the network to de- 
liver a service, based on the individual customer 
requirements for the network. The collection of 
local policies determines the overall network policy 
for a given service. 

In most cases, the network policy is based on 
the servers' capacity to deliver a given service. The 
capacity of the given service, however, can be 
changed with the addition or subtraction of servers 
to the network. In either case, the changes are 
made known to the broker and are transparent to 
the clients in the network. 

Upon startup, the broker develops a linked list 
data structure containing sets of server entries for 
each offered service corresponding to the local 
policy obtained for each server. According to one 
aspect of the invention, at any given time, the 
broker monitors a subset of those entries as a 
"preview window". The broker regularly rotates dif- 
ferent servers into and out of the previous window. 
The broker suggests an entry in the preview win- 
dow, upon receiving a client request, provided the 
entry has the available resources for the client. 

An advantage of the preview window is to 
substantially decrease the number of servers which 
must be monitored by the broker in a network. 
Because the broker maintains current status in- 
formation on only a subset of the servers during a 
given time interval, the number of status messages 
required to be transmitted over the network is 
reduced. This results in a reduction of computa- 
tional overhead for the broker and communications 
overhead on the network. 



In this embodiment, the broker assigns servers 
in a round robin fashion to ensure that the loss of a 
single server does not have a major impact upon 
clients that request access at similar times. The 

s application of the round robin server distribution, 
however, is regulated by use of a "scan weight" 
parameter for each server. The scan weight is 
defined as the number of client requests which can 
be satisfied by a server before that server is re- 

jo moved from the preview window. 

The advantages of the broker can be achieved 
with only a minimal increase in connect time from 
client to server. This is because the broker uses 
the preview window to monitor server status in- 

;s formation prior to receiving any client requests. 
The broker also uses the scan weight value to 
reduce the frequency by which the preview window 
is changed thus further increasing accurate server 
suggestions by the broker. Therefore, the incre- 

20 mental client connect time, as opposed to a direct 
client-server connection, is only increased by the 
time needed to contact the broker and receive a 
suggestion. 

In a further embodiment, the broker suggests 
25 to a client both the top server entry and the next 
active server entry in the preview window. By sug- 
gesting two possible servers, the broker compen- 
sates for the case in which a failure of the first 
server is alleviated without the need to recontact 
oo the broker, thus decreasing the load on the net- 
work. 

Another embodiment of the present invention 
makes use of multiple brokers for suggesting serv- 
ers to multiple different clients. The ability to have 
05 multiple brokers running simultaneously provides a 
highly reliable service by alleviating any single 
point of failure. 

<*o Brief Description of The Drawings 

Figure 1 is a block diagram illustrating the 
environment of the present invention. 

Figure 2 is a block diagram of a network 
J5 architecture including the present invention. 

Figure 2A is a block diagram conceptually 
illustrating the broker mechanism of the present 
invention. 

Figure 3 is a flow chart describing the mod- 
50 elling of a network policy according to the present 
invention. 

Figure 4 is a conceptual block diagram of 
the broker mechanism in Figure 2. 

Figures 5 and 5A are examples showing the 
ss operation of server datastructures used in the 
present invention. 

Figures 6 and 6A are flow charts describing 
the operation of the broker mechanism of the 
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present invention. 

Figure 7 is a conceptual block diagram of an 
embodiment of the present invention. 

Detailed Description of the Invention 



I. Network Environment 

Referring to Figure 1, there is shown a model 
block diagram of a system enhanced by the 
present invention. In a network 5, a plurality of 
users or clients, generally designated 10, each 
have access to a plurality of servers, generally 
designated 20. Some number of the servers 20 can 
provide access to services Ai -A n requested by one 
of the clients 10. When the client 10 requests 
access to a service via one of the servers 20. a 
connection is made from the selected client 10 
through the server 20. As can be seen in Figure 1 , 
a plurality of servers 20 are available to make the 
requested connection. Therefore, it becomes a 
problem to know which client 10 should connect to 
which server 20. Further, the resource capacity of 
the server 20 must be known in order to make an 
appropriate connection. Because the server re- 
sources have various and different capabilities, i.e., 
small CPU size, large CPU size, used and unused 
capacities, different serial line speeds, etc., dif- 
ferent servers 20 are more appropriate for a par- 
ticular client request. Also, it is necessary to know 
the service level desired by the client 10. 

Figure 2 is an example of a network architec- 
ture incorporating the present invention. The net- 
work 5 includes a plurality of servers 21-27 and 
clients 11-19 coupled to a communications medium 
6. e.g.. an Ethernet. A broker, conceptually shown 
as block 30. is also coupled to the communications 
medium 6. Further, a distributed repository 42 or 
44 is illustratively coupled to the communication 
medium 6 for storing network policy. These reposi- 
tories may be replications of each other distributed 
throughout the network. Each server can provide 
access to various services Ai-A„ for a requesting 
client 11-19. In operation, the broker 30 receives 
the local policies from the repository 42 or 44 for 
building data structures for each service supported 
by the servers, processes client requests for a 
service, and responds in accordance with network 
policy with one or more server suggestions to the 
client. 

Figure 2A conceptually illustrates the architec- 
tural diagram of Figure 2. A broker mechanism 30 
is used to suggest to clients 11-19 an appropriate 
server 21-26 for delivering the requested service 
(service A1 or A2). Further, individual servers 23, 
24 and 25 can provide more than one service. 
While figure 2A only illustrates two services, it is 



apparent that the broker 30 can suggest servers to 
clients requesting any number of different services. 
When a particular client, shown as client 13, re- 
quests access to service Ai. the client 13 places a 
s request with the broker 30 on path 54. The broker 
30 suggests an appropriate server from server set 
21-24 to the client 13. 



to II. Modelling 

A modelling process is used to efficiently de- 
termine the allocation of resources when designing 
a network. The modelling is accomplished by the 
ts network manager both prior to implementing the 
network and upon making subsequent changes to 
the network. In the modelling process factors are 
taken into account such as whether data transmis- 
sions during the use of a particular network service 
20 are of a bulk or interactive (bursty) nature and their 
effect on resource capacities. Because bulk data 
transfers usually have a high transfer rate i.e.. an 
entire floppy diskette of data is transferred and, on 
the other hand, interactive data transfers generally 
25 are of a short, bursty nature, it is generally possible 
in a given server to support more interactive data 
transfers than bulk data transfers. 

Figure 3 is a flow chart depicting the modelling 
process that occurs in the development of the 
30 network policy to be implemented by the broker 
mechanism for each service. 

The modelling begins by determining the ser- 
vice characteristics that are desired by the cus- 
tomer, i.e. the various possible actions, and the 
35 parameters of the server in the network, i.e. the 
resources of the server. Both the server parameters 
and required service characteristics are inputs to a 
modelling process such as is described in 
"Processor - sharing queuing model for time* 
40 shared systems with bulk arrivals", Kleinrock et al, 
Networks v.l n.1 pp. 1-13 (1971) or "Models for 
Computer Networks", Kleinrock, IEEE Int. Confer- 
ence on Communications. Conf. Rec, Boulder Co. 
June 9-11 Session 21 pp. 9-16 (1969). 

HI. Network Policy 

The model produces a prediction of the mea- 
so sured performance characteristics of each server 
based on the performance desired for each service 
offered by that service. This prediction is compared 
to the desired performance for each service to 
check if the server meets the performance limita- 
55 tions. If the prediction matches the desired perfor- 
mance, then the local policy for that particular 
server has been obtained. However, if the predic- 
tion does not match the desired performance, then 
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the local policy parameters of the server and/or the 
service characteristics are varied before being 
modeled again. This process continues until the 
server prediction matches the desired performance 
thus developing the local policy for the server. 

Next, the modelling process checks whether a 
local policy has been established for each server in 
the network. If not, then the above process is 
repeated. Once all local policies have been deter- 
mined, the local policies are collected to form a 
network policy for the entire network. The network 
policy is stored in the distributed repository 42 or 
44 as shown in Figure 2. 

When customers set up their network, they 
therefore establish a network policy to allocate re- 
sources for each service. Policy decisions must be 
cognizant of all of the available factors made prior 
to implementing the system, i.e., based on the 
physical constraints of the hardware, the commu- 
nication lines, the price factor for the product, the 
usage load. i.e.. heavy, medium, light, fast CPUs, 
slow CPUs and other appropriate factors. A broker 
implements the network policy when suggesting an 
appropriate server to maximize the efficiency of the 
complex network. 



IV. Broker 

An advantage of the invention allows the broker 
30 (Figure 2A) to operate when there is; a network 
policy for a given sen/ice; a method to easily 
determine the current usage of the server relative 
to the established local policy; and servers which 
can enforce their local policy e.g. by. rejecting any 
connection attempted beyond their local policy lim- 
it. These factors are used by the broker mecha- 
nism 30 to suggest a server 21-26 to a requesting 
client 13 based on the collection of local server 
policies in the broker. 

The data structures of the broker mechanism 
30 are formed from an application of the distributed 
repository storing the network policy for each ser- 
vice from which the broker linked list data struc- 
tures can be buiit. Many conventional means such 
as name server computer programs are available to 
facilitate the creation of these broker linked list data 
structures. The distributed repository is a non-vola- 
tile storage area which holds the collection of local 
policies and the attributes of how each supporting 
server supports a service. 

The repository is distributed throughout the 
network. As part of the broker startup procedures, 
the broker 30 extracts from the repository attribute 
information about each of the services it imple- 
ments, i.e.. service Ai-A n as shown in Figure 1. 
The repository is necessary to store the network 
policy in the event of a broker failure as the broker 



functions to compare current server capacity to 
network policy. 

Figure 4 is a conceptual diagram showing an 
example of the data structures produced by the 
5 code in the broker mechanism 30. The data struc- 
ture shown inside the broker 30 are linked lists of 
entries created by the broker code. 

The broker obtains the entries to create the 
data structures from the distributed repository 42. 

io A service list 71 is generated for those services 
found in the repository 42. Further, a server list 74 
is created for each service in the service list 71 to 
hold the local policy information for the particular 
servers 21-26 that support the service. Lastly, the 

is broker creates a "server status block* which con- 
tains a number of server connection entries 922. 
923. 924 and 926. there are being one connection 
entry in the server status block for each server 22. 
23. 24 and 26 which currently is in the "preview 

20 window" of at least one service. (Preview status will 
be defined below.) Each connection entry stores 
the current status information for its corresponding 
server. The policy information contained in the 
server list and service lists remains static, while the 

25 server status block information is of a dynamic or 
volatile nature. 

A server connection section 75 of the broker 30 
establishes communication paths 31-34 with the 
servers referred to in the preceding paragraph. The 

30 communication paths 31-34 allow the broker to poll 
each coupled server (22. 23. 24, 26) to receive its 
status. The status of the servers 22. 23. 24 and 26 
is stored in connection entries 922. 923. 924 and 
926, respectively, within the server status block. In 

35 response to subsequent client requests for service, 
the broker examines these connection entries to 
determine each coupled servers capacity or avail- 
ability to deliver a requested service, as will be 
described below with reference to Figures 5 and 

40 5A. The server connection code 75 therefore sup- 
ports a list of connection entries 922-926 that map 
(80-84) to a select number of server entries in the 
server lists 74 for each of the services in service 
list 71. As shown in Figures 4. a server 24 can 

<*5 overlap between service offerings. The server con- 
nection code 75 may therefore have several server 
lists 74 with entries pointing to a single server 
connection. This pooling of server connections is 
important for providing multiple service offerings 

so from one broker location. 



1 . Preview Window 

55 

During the broker's startup, data structures are 
developed in the broker. The data structures in- 
clude a service list 71 and server lists 74 having 
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sets of server entries (121-125) and (223-226) cor- 
responding to the servers (21-25) and (23-26) for 
each service (Ai & A 2 ) in the service list 71. The 
data structure information is provided from the re- 
pository 42. The broker 30 then monitors, via s 
couplings 80:84. subsets (22. 23 & 24) and (24 & 
26) of the servers from the above sets to form a 
preview window for each service. The size of the 
preview window is predetermined according to the 
network policy and stored as an attribute of the jo 
network policy in the repository 42. The preview 
windows 72 ensure that a sufficient number of 
servers, i.e., based upon the network policy for 
each service, are coupled and providing status to 
the broker 30 for each service before a client /s 
request is made. The si2e of the preview window 
generally reflects the number of servers necessary 
to satisfy the average rate of client requests re- 
ceived by the broker. By using preview windows, 
the connection time from client to servers is re- 20 
duced by accumulating status and policy informa- 
tion in the broker in advance of the client request. 

Without using the preview windows 72. the 
preconnectfon time for a client to receive data from 
a service would be the accumulation of: (client 25 
connect time to broker) + (broker connect time to 
server location) + (server startup time) + 
(accumulation of connect times needed to find a 
server location having unassigned capacity). By 
monitoring the resources of the servers contained 30 
in the preview windows via communication paths 
31-34 associated with each service, the broker 30 
can suggest the top entry in the preview window to 
a client requesting that particular service. The sug- 
gestion is made provided the entry has the avail- 35 
able resources. If an entry does not have the 
available resources it is removed from the preview 
window. Servers are thus regularly rotated in and 
out of the preview window. 

Figures 5 and 5A illustrate by example the data 4Q 
structures within each server (shown here as serv- 
ers 1 and 2) to indicate server capacity and status 
to deliver a requested service. The status informa- 
tion is provided to the broker 30 for comparing the 
capacity to the local policy for each server as 45 
shown by communication paths 31-34 in Figure 4. 

In Figure 5. server 1 is shown supporting two 
services 101 and 102 having service names A, and 
A a , respectively. Similarly, servsr 2 supports ser- 
vices 103 and 104 having service names Ai and so 
A 2 . Associated with each service 101-104 is a 
client capacity number 111-114 indicating the num- 
ber of clients that can be processed by each server 
for the particular service. The client capacity num- 
ber reflects the server's local policy for each ser- 55 
vice. As shown in Figure 5. the client capacity 
number can be a scalar value which is reduced as 
the server increases its load. The current value of 



the capacity number 111-114 is therefore checked 
by the broker whenever the broker tries to use the 
server. 

A second implementation of the database of 
server 1 is shown in Figure 5A wherein client slots 
105-108 are assigned to each service A, and A 2 • 
(101 and 102). For example, assuming each server 
has four client slots, two client slots (105. 106 and 
107, 108) can be allotted for each service 101 and 
102, respectively in server 1. This is equivalent to a 
client capacity number of two for each service 101 
or 102. Client slots allow the broker to' determine 
the availability of servers by checking a flag in- 
dicating whether particular client slots are used. 

However, a more powerful use of client slots is 
achieved in server 2 as shown in Figure 5A by 
allowing certain client slots to provide multiple ser- 
vices. Again, only four client slots are allocated for 
server 2. The first client slot 115 is dedicated for 
use with service A, (103) and the second client slot 
M8 is provided for service A 2 (104). in this case, 
however, the third and fourth client slots are made 
available to each service 116, 11 7, 119. 121. 
Therefore, if three requests are received for service 
A 2 and only one request for service At. then by 
making the client slots available for use with each 
service, all of the requests can be satisfied. Again, 
this is implemented by the server connection sec- 
tion 75 (Figure 4) checking flags to determine the 
availability of each client slot. These flags indicate 
the status for the servers against which the local 
policies are checked in connection entries 922-926. 

Through the use of the preview window and the 
overlapping of servers to provide different services, 
the broker mechanism 30 thus reduces the number 
of active network connections (31-34) necessary to 
poll the servers to obtain their status. Otherwise, 
active connections would be required from all of 
the servers in the network. Therefore, only a rea- 
sonably managed subset of servers is maintained 
by the broker 30 as active connections to reduce 
message traffic on the network and to simplify the 
computational overhead in the broker. 



B. Scan Weights 



Referring again to Figure 4, because the ca- 
pacity of each server to deliver a given service 
may not be equal depending upon the network 
policy, an additional parameter termed scan weight 
73 is added. The scan weight 73 is the number of 
client requests which can be satisfied from a server 
before the particular server is removed from the 
preview window 72. Each server is assigned a 
particular scan weight value for each service by the 
network manager. The scan weight 73 allows the 
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network manager to apply the network policy to 
more efficiently assign clients 10 to servers in a 
round-robin manner. The values chosen for the 
scan weight are developed as part of the capacity 
planning modelled in Figure 3. 

An example of scan weight operation is given 
in the server list 74 for service Ai as shown in 
Figure 4. Five servers 21. 22, 23. 24. and 25 
having server entries 121*125. respectively, are 
determined to have the following capacities to ac- 
cess a service for a client: server 21.2 clients(lO); 
server 22.6 . clients(10); server 23.2 clients(iO); 
server 24.4 clients(lO); and server 25,2 clients(lO). 
Without scan weight, the broker mechanism 30, 
using a purely round robin method of assigning 
servers, would reduce the list of five available serv- 
ers 21-25 to just two available servers 22 and 24 
after only 10 client requests have been suggested. 
This occurs because the servers having the least 
capacity, i.e. 21, 23 and 25. are suggested as often 
as the other servers, thus quickly using their ca- 
pacity. After the first ten requests, only servers 22 
and 24 have any capacity remaining. Further, only 
one server 22 wpuld be available after the next four 
client requests. This rapid reduction in the available 
servers can produce single failure points which 
may disrupt a network. 

A scan weight parameter 73 is therefore deter- 
mined based on an equal distribution of the server 
capacities to handle client requests. The scan 
weight 73 controls the number of clients assigned 
to a particular server when it is at the top of the 
preview window. In our example, an appropriate 
allocation of clients per scan weight may be as- 
signed as follows: 21.1 client(lO). 22.3 ciients(lO): 
23.1 client(10): 24.2 clients(lO); and 25.1(10) client. 
By using these scan weight values, the servers 
having the greatest capacity, i.e. 22 and 24. will be 
assigned to multiple clients before being removed 
from the preview window. Thus, the client requests 
are evenly distributed across all available servers 
21-25 based on their capacity. In this example, four 
servers would still be available after the first ten 
client requests have been satisfied. 



C. CLIENT CONNECTION and MANAGEMENT OF 
B ROKER 

(}■-■■ 

The client connection section 70 of the broker 
30 is the interface for providing server suggestions 
to the clients. A client's request for a service is 
received on path 54. Client connection section 70 
checks to insure that the service is located in the 
service list 71 of supported services in the broker 
30. Further, client connection section 70 performs 
the necessary steps to suggest a server to the 



accessing client. 

The management section 76 of the broker 30 
provides control and status information relative to 
the operation of the broker 30. For example, the 
5 management section 76 can enable and disable 
service names, examines the size of the preview 
window 72. displays information on the current 
entries in the preview window, or other manage- 
ment functions. 

jo 

V, BROKER OPERATION 

The operation of Figure 4 is described by the 

/s flow charts of Figures 6 and 6A. Figure 6 describes 
the inclusion of the local policies into the operating 
broker mechanism 30. Figure 6A describes the 
operation of the broker upon receiving a client 
request for a server, 

20 In operation upon broker 30 start-up, the ser- 

vices i.e.. service Ai, Aj or A}, are obtained from 
the network list in the distributed repository 42 
functioning as a directory for all of the services. 
Once the service is found, the broker 30 begins to 

25 build a service list data structure 71 which includes 
the attributes for each of the services. Next, the 
server information for the particular service is ob- 
tained from the repository 42. If no servers are 
found, then a new service is obtained from the 

30 repository 42 and the process is repeated. How- 
ever, if a server is found, then a server list data 
. structure 74 is built for the particular service. The 
server list data structure 74 contains the local poii- ' 
cy for each server supporting the service and the 

35 scan weight 73 for each server in the server list 74. 
Once all of the services stored in the repository are 
found, then the server connection section 75 be- 
gins to build the status connections used for the 
preview windows 72 (or each service. 

40 Referring to Figures 4 and 6A, the operation of 

the broker upon receiving a client request for a 
service is described. The broker 30 receives a 
message from the client 1 3 via path 54 containing 
the name of the service requested, i.e., service Ai, 

js A 2 or A3. The client connection section 70 receives 
the request and checks whether the service list 71 
exists in the broker. If the service list 71 exists, the 
• broker 30 checks whether the particular service 
requested (in this example service Aa) is contained 

so in the service list 71. The broker 30 then obtains 
the top entry. 226 in the preview window 72 for 
service Aj. Next, the broker checks whether the 
connection entry 926 is active, i.e.. is there a 
connection from broker to server as on path 34. If it 

55 is not active, then the entry 226 is removed from 
the preview window 72. However, if the entry 226 is 
active, then the local policy information for the 
associated server 26 is obtained from entry 226 in 
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the server list 74. 

The local policy limit is then checked in con- 
nection entry 926 against the status information 
received for the server 26 on path 34. This is 
accomplished as described above in figures 5 and 5 
5A by checking either the client capacity number 
or the availability of client slots, depending upon 
the type of status indication that is used. 

The availability of server 26 to support service 
A 2 is checked to make sure that its policy limit is to 
not exceeded. If the server 26 has the necessary 
capacity as determined by either the client slots or 
the client capacity number, i.e. the current value is 
less than the client capacity number or there are 
available client slots as indicated by the flags, then, 15 
a message is sent to the client 13 suggesting 
server 26 to be used to deliver service A 2 . The 
scan weight value 73 for server entry 226 is de- 
creased and is checked to determine if the entry 
226 should be removed from the preview window 20 
72. The broker continues by refilling the preview 
window if necessary. 

If, however, server 26 does not have the avail- 
able capacity, then the next entry 224 in the pre- 
view window 72 is checked. This process continues 25 
until either an entry is found or no server is deter- 
mined to be available. It is thus apparent that 
broker 30 need only check the status of a server 
when a request for a particular service is received 
and that particular server is in the preview window. 30 
For each entry in the preview window not having 
the necessary capacity or having been previously 
assigned, the entry is rotated out of the preview 
window and another entry refills the preview win- 
dow. It may occur, however, that no servers are 35 
available to refill the preview window, in which case 
the size of the preview window would be reduced. 

Under normal operations, the broker mecha- 
nism efficiently operates to receive client requests 
and suggest servers. However, if at any time during *o 
a request, the service list, name of the service or 
preview window do not exist, then the broker 30 
will send an error message to the client 12. 

An alternate embodiment of the present inven- 
tion has the broker 30 suggest to the client 12, not js 
only the top server entry 226 but also the next 
active server entry 225 in the preview window 72. 

In operation, upon receiving a client request, 
the broker again would check the entry in the 
preview window. Once the broker finds an entry so 
having the available capacity, it suggests that entry 
along with the next entry in the preview window. In 
this embodiment, only the scan weight of the first 
entry is decreased. The client then will attempt to 
access the service through the first entry. If how- 55 
ever, the first entry fails for any reason, then the 
client attempts to use the second server entry 
without having to reconnect to the broker. 
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When using this embodiment, the broker does 
not need to continuously check the status of the 
two entries. The status will be updated the next 
time the broker checks on those particular server 
entries. 

The use of two entry suggestions is useful in 
the event of a failure by the first server to deliver 
the requested service. Failure of a server can occur 
due to other clients accessing the server directly 
thus using its capacity, failure of the hardware, line 
damage, etc. Thus, suggesting two servers pro- 
vides for the situation in which the first server failed 
during the client's connection time to the server 
using the broker. The inclusion of a second server 
suggestion provides the client with an alternate 
server without having to recontact the broker. Thus, 
client connection time can be decreased by using 
two server suggestions. 

As shown conceptually in Figure 7, another 
embodiment of the present invention incorporates 
multiple brokers 30 and 31 for suggesting servers 
to different clients 11-19. The brokers 30-31 can be 
replications of each other supporting the same ser- 
vices. The brokers operate independently of each 
other to provide a high availability factor to the 
clients. An attendant tradeoff for the availability is 
an increase in overhead on the network as status 
information for the monitored servers in the preview 
window must go to each broker 30, 31. If however, 
the rate of client requests to the brokers 30, 31 is 
slow, then the brokers can adjust the rate at which 
they poll the servers for their status in the preview 
window. By reducing the polling rate in proportion 
to the number of brokers, the message traffic on 
the network will remain substantially the same as 
for a single broker while still providing high avail- 
ability and eliminating the broker as a single point 
of failure. 

Using multiple brokers, the scan weight value 
increases is a linear function of the number of 
brokers in the network provided the network policy 
is consistent among the brokers. This occurs be- 
cause each broker maintains a separate preview 
window and yet the enforcement of the local poli- 
cies is carried out by each individual server. Be- 
cause servers for the same service will be con- 
tained in each broker's preview window and the 
brokers are independent of each other, the servers 
will be rotated independently of the other brokers 
preview window. Thus, because the server has the 
same scan weight in two separate preview win- 
dows, the scan weight value is effectively doubled. 

The ability to have multiple brokers 30, 31 
operating simultaneously provides a highly reliable 
system by alleviating any single point of failure. 
Further, the clients gain an increased opportunity to 
use a broker to suggest a server for delivering the 
requested service. 
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A further embodiment of the present invention 
uses multiple server lists having different priorities. 
The different lists each have their own preview 
windows. The use of prioritized server lists allows 
the client to obtain service when the servers in the 
higher priority service list are unavailable. This is 
done by automatically redirecting the client re- 
quests to the lower server list to provide the ser- 
vice, albeit at a less desirable service level, without 
the client needing to make a request for access to 
an additional service name. 



Claims 

1 . A method for allocating a plurality of servers, 
each server having an available resource capacity, 
to a plurality of clients for delivering a plurality of 
services to said clients, the method comprising the 
steps of: 

a) developing a network policy for said plu- 
rality of servers by collecting a local policy for each 
of said servers; 

b) receiving client requests for said services 
in at least one broker; 

c) suggesting by the broker one of said 
servers to one of said clients making a request 
based on the network policy anu available resource 
capacity, said server being suggesteu having* ii-.o 
available resource capacity to deliver said service. 

2. A method according to claim 1 further com- 
prising the step of enforcing the local policy for 
each of said servers. 

3. A method according to claim 2 wherein said 
step of suggesting a server further includes: 

a) creating a service list within said broker of 
available services from said network policy; 

b) creating a server list, containing server 
entries of available servers from said network poli- 
cy, for supporting each of said services in said 
service list; and 

c) monitoring a subset of said server entries 
in said server list for each service to form a pre- 
view window in said broker for suggesting said 
servers represented in said server list to said cli- 
ents. 

4. A method according to claim 3 wherein said 
step of monitoring said subset further includes the 
steps of: 

a) coupling a status path indicating available 
client slots from at least one of said plurality of 
servers supporting one of said services to said 
broker; 

b) comparing the available client slots for a 
first of said coupled servers being monitored 
against said first server's local policy; and 

c) determining whether said first server has 
an available client slot to deliver the service re- 



quested by said clients. 

5. A method according to claim 4 wherein said 
step of suggesting is m3de when one of said 
servers being monitored has an available client slot 

s to deliver said service. 

6. A method according to claim 5 wherein said 
step of enforcing said local policy is performed by 
said suggested server rejecting any client connec- 
tion attempt exceeding its local policy limit. 

10 7. A method according to claim 6 further com- 

prising the steps of: 

a) disconnecting the coupling of said first 
server when said first server's status path indicates 
no available client slots wherein its local policy limit 

is is exceeded; and 

b) subsequently coupling to the broker an- 
other of said plurality of servers in said server list 
supporting said service having available client 
slots. 

20 8. A method according to claim 7 further com- 

prising the steps of: 

a) developing a scan weight value for each 
of said plura! : ;y of servers supporting each service 
based on r jd<> network policy; 

25 t) creating a scan weight entry containing 

the st un weight value for each server entry in said 
sc-.*er list; 

c) decreasing the scan weight value for said 
first server in the preview window after said first 

30 server is suggested to said client: and 

d) removing said first server from the pre- 
view window when said scan weight value is zero. 

9. A method according to claim 1 wherein said 
step of developing a network policy includes: 

35 a) determining a set of service characteris- 

tics for each of said services; 

b) modelling said sets of service characteris- 
tics with the available resources of one of said 
servers to determine a service capability for said * 

<*o one server; 

c) comparing the service capability with an 
intended local policy for said one server to deter- 
mine if there is a matching local policy; 

d) varying the sets of service characteristics 
4S and the available resources until said comparing 

step produces a matching local policy; 

e) storing said matching local policy; 

f) repeating steps a) * e) for each of said 
plurality of servers: and 

50 g) collecting said matching local policies to 

obtain a network policy. 

10. A method according to claim 1 wherein 
said computer network uses multiple brokers. 

11. A method according to claim 10 wherein 
55 said multiple brokers are exact replicas of each 

other and operating independently. 

12. A method for allocating a plurality of serv- 
ers, each server having an available resource ca- 
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pacity, to a' plurality of clients in a network for 
delivering a plurality of services to said clients, the 
method comprising the steps of: 

a) receiving client requests for said services 

in at least one broker; and 5 

b) forming a preview window of said plurality 
of servers and in said broker; and 

c) suggesting said servers represented in 
said preview window to said clients whereby com- 
munications overhead on the network is reduced. to 

13, A method according to claim 2 wherein 
said steps of forming a preview window and sug- 
gesting said servers further comprises: 

a) developing a network policy for said plu- 
rality of servers by collecting a local policy for each ;s 
of said servers; 

b) creating a- service list within said broker of 
available services from said network policy; 

c) creating a server list, containing server 
entries cf available servers from said network poli- 20 
cy, for supporting each of said services in said 
service list; and 

r d) monitoring a subset of said server entries 
in the server list for each server to form the pre- 
view window for each service. 25 

14. A method according to claim 13 wherein 
caid step of monitoring a sub?*i further comprises 
the steps of: 

a) coupling a status path indicating available 
client slots from at least one of said plurality of 30 
servers supporting one of said services to said 
broker; 

b) comparing the available client slots for a 
first of said coupled servers being monitored 
against said first server's local policy; and 35 

c) determining whether said first server has 
an available client slot to deliver the service re- 
quested by said clients. 

15. A method according to claim 14 wherein 

said step of suggesting is made when one of said <*o 
servers being monitored has an available client slot 
to deliver said service. 

16. A method according to claim 15 wherein 
said step of enforcing said local policy is per- 
formed by said suggested server rejecting any 45 
client connection attempt exceeding its local policy 
limit. 

17. A method according to claim 16 further 
comprising the steps of: 

a) disconnecting the coupling of said first so 
server when said first server's status path indicates 

no available client slots wherein its local policy limit 
is exceeded; and 

b) subsequently coupling to the broker an- 
other of said plurality of servers in said server list ss 
supporting said service having available client 
slots. 

18. A method according to claim 17 further 



comprising the steps of: 

a) developing a scan weight value for each 
of said plurality of servers supporting each service 
based on said network policy; 

b) creating a scan weight entry containing 
the scan weight value for each server entry in said 
server list; 

c) decreasing the scan weight value for said 
first server in the preview window after said first 
server is suggested to said client; and 

d) removing said first server from the pre- 
view window when said scan weight value is zero. 

19. A method according to claim 13 wherein 
said step of developing a network policy includes: 

a) determining a set of service characteris- 
tics for each of said services; 

b) modelling said sets of service characteris- 
tics with the available resources of one of said 
servers to determine a service capability for said 
one server; 

c) comparing the service capability with an 
intended local policy for said one server to deter- 
mine if there is a matching local policy; 

d) varying the sets of service characteristics 
and the available resources until said comparing 
step produces a matching local policy; 

e) storing said matching local policy; 

f) repeating steps a) - e) for each of said 
plurality of servers; and 

g) collecting said matching local policies to 
obtain a network policy. 

20. A method according to claim 12 wherein 
said computer network uses multiple brokers. 

21. A method according to claim 20 wherein 
said multiple brokers are exact replicas of each 
other operating independently. 

22. A device for allocating a plurality of serv- 
ers, each having an available resource capacity, to 
a plurality of clients for delivering one of a plurality 
of services to said clients, said servers and said 
clients being arranged in a computer network, com- 
prising: 

a) a broker including: 

(i) means for receiving client requests for 
said services; and 

(ii) means for suggesting by the broker one 
of said servers to one of said clients making a 
request based on a network policy and available 
resource capacity, said one server being suggest- 
ed having the available resource capacity to deliver 
said service; said means for suggesting further 
comprising: 

1 ) means for creating a service list, within 
said broker, of available services from said network 
policy; 

2) means for creating a server list, con- 
taining server entries of available servers from said 
network policy, for supporting each of said services 
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in said service list; and 

3) means for monitoring a subset o» said 
server entries in said server list that forms a pre- 
view window in said broker for suggesting said 
servers represented in said server list to said cli- 
ents. 

23. A device according to claim 22 further 
comprising means for enforcing said local policy 
for each of said servers. 

24. A device according to claim 23 wherein 
said network policy is a collection of a local poli- 
cies for each of said servers and wherein said 
means for monitoring further comprises: 

a) a status path coupled from at least one of 
said plurality of servers supporting one of said 
services indicating available client slots for the 
server to said broker: 

b) means for comparing the available client 
slots for a first of said coupled servers being mon- 
itored against said first server's local policy: and 

c) means for determining whether said first 
server has an available client slot to deliver the 
service requested by said clients. 

25. A device according to claim 24 wherein 
said means for suggesting sends a message to 
said client when one of said servers has an avail- 
able client slot to deliver said service. 

26. A device according to claim 25 wherein 
said means for enforcing includes said one server 
rejecting any connection attempt exceeding its lo- 
cal policy. 

27. A device according to claim 26 further 
comprising: 

a) a scan weight value developed for each of 
said plurality of servers based on said network 
policy; 

b) a scan weight entry containing the scan 
weight value stored in said broker for each server 
entry in said server list; 

c) means for decreasing the scan weight 
value for said first server in the preview window 
after said first server is suggested to said client: 
and 

d) means for removing said first server from 
the preview window when said scan weight value is 
zero. 

28. A broker according to claim 24 further 
comprising means for developing the network poli- 
cy including: 

a) means for modelling a plurality of sets of 
service characteristics with the available resources 
of one of said servers to determine a service 
capability for said one server; 

b) means for comparing the service capabil- 
ity with an intended local policy for said one server 
to determine if there is a matching local policy; 

c) means for varying the sets of service 
characteristics and the available resources until 



said comparing step produces a matching local 
policy; 

d) means for storing said matching local 

policy. 

5 29. A computer network comprising: 

a) at least two brokers for allocating a plural- 
ity of servers having an available resource capacity 
to a plurality of clients for delivering one of a 
plurality of services to said clients: 

to b) said brokers comprising: 

(i) means for developing a network policy for said 
plurality of servers by collecting a local policy for 
each of said servers: 

(ii) means for receiving client requests for said 
ts services in said broker: and 

(iii) means for suggesting by the broker one of said 
servers to one of said clients making a request 
based on the network policy and available resource 
capacity, said one server being suggested having 

20 the available resource capacity to deliver said ser- 
vice: and 

c) means for enforcing said local policy for 
each of said servers. 
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